Columbia Kermit/kermit.zip/newsgroups/misc.19990725-20000114/[e-mail] _Mon Jan 10 21:24:17 2000.msg

Internet Message Format | 2020-01-01 | 5KB

Return-Path: <[e-mail]>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
    by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id VAA26097
    for <[e-mail]>; Mon, 10 Jan 2000 21:24:16 -0500 (EST)
Received: (from news@localhost)
    by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id VAA20502
    for [e-mail]; Mon, 10 Jan 2000 21:03:47 -0500 (EST)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: [e-mail] (Frank da Cruz)
Subject: Case Study #4: Automatic text/binary mode switching
Date: 11 Jan 2000 02:03:46 GMT
Organization: Columbia University
Message-ID: <85e322$k0k$[e-mail]>
To: [e-mail]


Today's topic is automatic text/binary file-transfer mode selection.

The manual goes into some detail about just what "text" and "binary"
mean, and what the consequences might be for choosing the wrong mode.
This discussion assumes you know all that.

One of the hallmarks of C-Kermit 7.0 is that it tries to do the right
thing for most people automatically whenever possible, by default, rather
than making everybody cope with myriad settings to accomplish what they
want.  It's not exactly artificial intelligence, more like layer upon
layer of tricks and ruses based on years of experience.

A common source of aggravation to users of any file-transfer software
(FTP, Zmodem, or Kermit) is when find you have transferred a file in the
wrong mode -- text when it should have been binary, or vice-versa.  The
fact is that on most platforms, application software has no good way of
telling the difference between a "text file" and a "binary file" on its
own.  That's why file-transfer programs have commands that make you do it.

Back in the old days, Kermit's rules were simple, modeled on those of FTP:
all files were transferred in text mode by default.  If you wanted want to
transfer files in binary mode, you had to give a command, SET FILE TYPE
BINARY.  From this point, all files would be transferred in binary mode
until you gave another SET FILE TYPE command to change the mode back to
TEXT.

In C-Kermit 7.0, the rules have changed, and in fact have become quite
complicated.  But since now it is all supposed to "just work", most people
will never need to know what they are.  A couple of new advances make this
possible:

 1. Kermit protocol now includes a provision for "automatic peer
    recognition".  If Kermit A is on Linux and Kermit B is on Solaris,
    they say "we are both on UNIX so we are alike" (modern versions of
    FTP do this too).  In this case, they automatically transfer
    everything in binary mode except when character-set translation has
    been requested.  When the two Kermits are not alike (e.g. some
    pairing of Unix, VMS, Windows, OS/2, OS-9, VM/CMS, etc), or if one
    of the Kermit partners fails to identify itself, then the
    text/binary file distinction is important.

 2. When the two Kermits do not have an "all-binary" connection (e.g.
    Unix-to-Unix without character-set translation), the file sender can
    switch automatically between text and binary mode on a per-file
    basis based on each filename.  The sender informs the receiver of
    transfer mode of each file (this works with all but the most
    primitive Kermit implementations).

The upshot is, if you send files from C-Kermit 7.0 to C-Kermit 5A or later
(on Unix, VMS, or other platform), to Kermit 95 (any version) or MS-DOS
Kermit 3.00 or later, the right stuff should happen.

When the two platforms are alike, all files are transferred in binary mode
unless you go out of your way to force text.  When the text/binary
distinction is significant, C-Kermit picks the mode for each file by
comparing its name with lists of text and binary filename patterns.  If a
filename doesn't match any of the patterns, then the file is sent in the
prevailing (SET FILE TYPE) mode, which, by new default, is BINARY.

Default lists are built in that catch the well-known types; you can see
them by typing SHOW PATTERNS.  Here's an example for UNIX:

 File binary-patterns:
  *.gz *.Z *.tgz *.gif *.tar *.zip *.o *.so *.a *.out *.exe *.jpg
  *.jpeg *.tif *.tiff *.pdf *.so.* *.class *.rpm *.bmp *.bz2 *.BMP
  *.dll *.doc *.vxd *.pdf *.xl* *.lzh *.lhz [wk]ermit

 File text-patterns:
  *.txt *.c *.h *.r *.w *.cpp *.ksc *.bwr *.upd *.html *.htm *.mss
  *.tex *.nr [Mm]akefile *.hex *.hqx *.for *.f77 *.f *.F *.s *.pas
  *.java *.el *.lisp *.sh *.perl *.awk *.sno *.spt *.sed *.TXT
  *read.me *READ.ME .* */.*

Of course you can change the lists by adding, removing, or replacing
patterns.

The utility of this feature becomes apparent when you want to transfer a
mixed group of files.  For example, suppose you want to propogate a
directory that contains a mixture of C source files, binaries, and ZIP or
compressed tar archives to a variety of platforms.  Now, for the first
time, "send *" does it right.

This is just an introduction.  For complete details on this topic, read
ckermit.txt Section 4.3, plus Section 4.9 about pattern syntax.

- Frank